[Previous] [Next] [Index] [Thread]

Keys, certificates and URNs

> far as software distribution goes, by far the best guarantee
>that it hasn't been tampered with is the digital signatures of the 
>authors themselves.  A signature by someone who hasn't closely 
>examined the code is quite a piece of lunacy, but I bet there will be
>plenty of suckers out there who will be impressed by some particular
>well-hyped chop.

This is why I believe the URN scheme to be connected to the certification
scheme.

URI: URN://w3.org/software/libwww_3_0.tar.Z

This means that the object was produced by w3.org and I should look for a
certificate from someone I trust that validates the w3.org key.


Inevitably there must be some elements of a certification hierarchy but
we don't want a monolithic scheme, the idea of a `root' is antithical
to the web. So we are all the root of our own personal (or site)
authentication hierarchies. I decide I trust the following:

My bank		//cash.com.ch/keys
My solicitors	//sue.grabbit.and.runne.com/keys
The government	//nsa.gov/authenticate
Fred		//fred.org/authenticate
etc.

Now I would trust various parties in various ways. I would trust my bank in
connection with payments but not the government. I would trust the government
to certify its own agencies, Attached to each of the authentication
agencies would be a list of the urns I would trust them to certify for.

Possibly this bumps into the URC scheme as well since it is on the
characteristics of the object that I want to make the match.


Checking the authorisation then becomes a matter of a URN lookup at the
specified authorisation agency. I try fred:

//fred.org/authenticate/w3.org/<key-id>

Back comes a signed key or an "I don't know" message or a "blacklisted"
message.


A simple method of implementing the URN scheme is to limit the primary
URN space to that of DNS. Ie you have to have an internic to play. We then
serve out a list of urn match patterns to provide the translations:

//w3.org/*	->	http://info.cern.ch/*
		->	http://www.lcs.mit.edu/w3.org/*
		->	etc.

or we might have a complex indirection. This would tend to be the case for 
governmental size organisations.

//dec.com/*	->	resolve://gatekeeper.dec.com/*
		->	etc

And gatekeeper keeps a list of the sub resolutions:

//dec.com/software/*	-> 	http://gatekeeper.dec.com/*
//dec.com/publicity/*	->	http://sales.dec.com/*


The w3.org key is a bad example since for many people W3O will be the main
trusted root. Not that it should make much difference aince I would expect 
all the security players to be `roots' of some sort.

One distinction to make, between storage and trust. To save bandwidth it
is probably best to keep most of the certificates in a common `virtual'
library with lots of mirrors. But the certificates could be signed by
almost anyone. Through the cache scheme the certificates would natrually
migrate to local caches. I would expect to have TIS, EIT, DEC, HP etc
in the local cache so the lookup hoopla is minimal.

On blacklists - we don't need them they are implicit in the cache scheme
we can send an if not modified or if not matching digest request for the
original. Eventualy the integrated cache scheme should cope with asynchronous
cancellation of cache objects.

The idea however is to emphasis corporate authentication rather than individual
authentication. A corporate key is unlikely to go walkies, or rather less likely
than those of individual employees.


I would like to also propose extending my certificate exchange proposal to
include some new tags :-

Authorised-Roles: hallam, root
Authorised-Activities: Payment; limit=CHF3000, Access


The authorised roles would be as in the current Shen spec. a role is
composited with the authorised name - e.g. hallam@w3.org

The activities tag would limit the activities for which the key was valid.
Ie the key above is authorised for use in small payments and for access
to data objects.

The main use for these tags would be for sub keys issued to individuals.
A master key would authorise the sub key but limit its validity. In this
way a corporation can limit the damage done by employee fraud (except if
the master key is blown).

Some suggestions:

1) A master key should have multiple signatures using different mechanisms
	for safety. Just in case RSA or DSS gets blown.

2) Some sort of counter signing scheme. A tag to say this key requires
	a counter signature from fred before a signature is valid. This
	would ease some comms problems.

--
Phill.
References: